Computer Science

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

  • Downloads：5528
  • Type：Epub+TxT+PDF+Mobi
  • Create Date：2021-03-08 03:18:58
  • Update Date：2025-09-07
  • Status：finish
  • Author：Robert C. Martin
  • ISBN：B0050JLC9Y
  • Environment：PC/Android/iPhone/iPad/Kindle
  • Download

Summary

The Much-Anticipated Follow-Up to “Uncle Bob’s” Highly Praised Clean Code

Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software。 They treat it as a craft。 They are professionals。

In The Clean Coder: A Code of Conduct for Professional Programmers ， legendary software expert Robert C。 Martin introduces the disciplines， techniques， tools， and practices of true software craftsmanship。

This book is packed with practical advice—about everything from estimating and coding to refactoring and testing。 It covers much more than technique: It is about attitude。 Martin shows how to approach software development with honor， self-respect， and pride; work well and work clean; communicate and estimate faithfully; face difficult decisions with clarity and honesty; and understand that deep knowledge comes with a responsibility to act。

Readers will learn
- What it means to behave as a true software craftsman
- How to deal with conflict， tight schedules， and unreasonable managers
- How to get into the flow of coding， and get past writer’s block
- How to handle unrelenting pressure and avoid burnout
- How to combine enduring attitudes with new development paradigms
- How to manage your time， and avoid blind alleys， marshes， bogs， and swamps
- How to foster environments where programmers and teams can thrive
- When to say “No”—and how to say it
- When to say “Yes”—and what yes really means

Great software is something to marvel at: powerful， elegant， functional， a pleasure to work with as both a developer and as a user。 Great software isn’t written by machines。 It is written by professionals with an unshakable commitment to craftsmanship。 The Clean Coder will help you become one of them—and earn the pride and fulfillment that they alone possess。

Download

Reviews

Christiaan ，

Starts out with psychology from the cold ground on how to behave in your work， regarding how much time you should spend， how you should deal with your boundaries， etc。 That was not soo good， but after that the book got better and better and matches the experiences I had while being a developer。

Svyatoslav Lavryk ，

This is a must read for any programmer。

David Carpinteiro ，

For whoever thinks this is a book where you will see lots of good code examples， code standards， code references。。。THIS IS NOT。Instead this book tries to explain what it means to be a professional not only as a developer， but for any computer science related work。If you are someone who is starting on the field of computer science， or someone already with some experience， if you never read this book。。。READ IT NOW。This should be a reference for our area。 And universities that require so many techn For whoever thinks this is a book where you will see lots of good code examples， code standards， code references。。。THIS IS NOT。Instead this book tries to explain what it means to be a professional not only as a developer， but for any computer science related work。If you are someone who is starting on the field of computer science， or someone already with some experience， if you never read this book。。。READ IT NOW。This should be a reference for our area。 And universities that require so many technical books， this should be something students in computer science should be told to grab and read as it will teach them what they will face on real word and how to perform it correctly。Congratulations for this excellent book and thank you。 。。。more

Peter Tillemans ，

A great overview of aspirational behaviors for coding professionals and crafts（wo）men。

Rémi ，

Another must-read book

André M。 Treffeisen ，

Probably should have read this book years ago， but never too late。 Lots of valuable anecdotes， some of which I also experienced。Am I a professional programmer？ I guess， not according to this code of conduct - or not yet。 Only some of the stuff mentioned am I doing currently。Does this book make you a professional programmer？ No， that's not the intention as far as I understand it。 It's giving inspiration and thoughts around the process of becoming a professional programmer。 Probably should have read this book years ago， but never too late。 Lots of valuable anecdotes， some of which I also experienced。Am I a professional programmer？ I guess， not according to this code of conduct - or not yet。 Only some of the stuff mentioned am I doing currently。Does this book make you a professional programmer？ No， that's not the intention as far as I understand it。 It's giving inspiration and thoughts around the process of becoming a professional programmer。 。。。more

Daniel ，

A must read for any software developer。

Qiaoyi Xu ，

An excellent book to learn to be a better programmer with higher standards

Brendan Sears ，

Everyone in every field should read this

Tiger Abrodi ，

A great book， in my a book every software engineer， should read。 I'd describe it as teaching you how to be a professional。 It talks about estimations， soft skills， working in a team， being humble， and much more！ A great book， in my a book every software engineer， should read。 I'd describe it as teaching you how to be a professional。 It talks about estimations， soft skills， working in a team， being humble， and much more！ 。。。more

Gilliano ，

Very good read for those who wants to be a better developer no matter what technology you work with。 I liked specially the author experiences related there， and how common some situations happens in the software development life cycle。 This helped me to think how could I be more prepared to these situations。

Lukas ，

Quite interesting reading from experienced developer and consultant， with specific situations and experience regarding professional programmers' behavior。 Covering areas like:- what professionalism is- how/when to say YES or NO- efficient coding and practicing- testing- time management， estimation- how to handle pressure and collaborationAlso add the author's experience and point of view about tooling。 Interesting reading also for non-programmers Quite interesting reading from experienced developer and consultant， with specific situations and experience regarding professional programmers' behavior。 Covering areas like:- what professionalism is- how/when to say YES or NO- efficient coding and practicing- testing- time management， estimation- how to handle pressure and collaborationAlso add the author's experience and point of view about tooling。 Interesting reading also for non-programmers 。。。more

Kerri Sharp ，

A must-read for any software programmer。 I was surprised by this book， I didn't expect to find that so many interesting stories from early in Bob's career which are still be relevant to today's world， a fact that I think Martin is trying to drive home by using examples from his career to illustrate his points。 I'm definitely guilty of thinking that because technology changes so fast， that the work must too， but that is wholy incorrect。 Developers today have many of the exact same issues that cre A must-read for any software programmer。 I was surprised by this book， I didn't expect to find that so many interesting stories from early in Bob's career which are still be relevant to today's world， a fact that I think Martin is trying to drive home by using examples from his career to illustrate his points。 I'm definitely guilty of thinking that because technology changes so fast， that the work must too， but that is wholy incorrect。 Developers today have many of the exact same issues that creatives getting paid throughout time have faced。 If you've ever been， or wish to be paid to write code then this book is for you。 。。。more

Daniel ，

Muy buen libro para cualquier profesional， enfocado al desarrollo IT pero aplicable a cualquier profesión！Muy recomendable！

Roman Fursov ，

Полагаю， что книга просто не подходит для тех людей， кто уже работает в индустрии。 Допускаю， что мысли в ней были бы неплохими для новичков。 В моём случае вышло， что вся книга - повторение того же， что я и так знаю。 Может быть， я уже "профессионал" в определении автора книгиНе могу поверить， что книга была опубликована в 2011 - кажется， что большая часть вещей уже была самоочевидна ещё тогда。 А на сегодняшний день и подавно。 Однако， повторюсь， для новичков все эти темы могут оказаться полезны и， Полагаю， что книга просто не подходит для тех людей， кто уже работает в индустрии。 Допускаю， что мысли в ней были бы неплохими для новичков。 В моём случае вышло， что вся книга - повторение того же， что я и так знаю。 Может быть， я уже "профессионал" в определении автора книгиНе могу поверить， что книга была опубликована в 2011 - кажется， что большая часть вещей уже была самоочевидна ещё тогда。 А на сегодняшний день и подавно。 Однако， повторюсь， для новичков все эти темы могут оказаться полезны и， читая книгу， они сразу наберут какой-то уровень понимания того， как делать надо， а как нет （но с оговорками）Что мне не понравилось:1） Категоричное утверждения о пользе какого-то подхода и технологии （TDD， 100% coverage， парное программирование）。 Можно было бы считать это набросом для дискуссии， но книга - это не подходящий для такого формат2） Реклама самого себя и своих проектов3） Личные истории из жизни， которые вообще мало вяжутся с происходящим， да ещё и повторяются 。。。more

Alexandre Fonseca ，

An arrogant book from an arrogant man。

Tuấn Nguyễn Quốc ，

this book is awesome， programmers should read it

David Karto ，

A greater tome of experience for those individuals who are brave enough to venture into the IT dungeons where dragons lurk everywhere。Especially helpful for those who wants to start their quest as a journeyman programmer。

Zbyszek Sokolowski ，

Świetna książka， zawarte treści są b pomocne i aktualne， parę cytatów:Znacznie łatwiej jest nie być profesjonalistą。 Nie trzeba wtedy brać odpowiedzialności za swoją pracę — tę można pozostawić pracodawcom。 Jeżeli nieprofesjonalista popełnia błąd， to pracodawca musi po nim posprzątać。 Jeżeli jednak błąd popełnia profesjonalista， to sam stara się go skorygować。Prawdziwy zawodowiec wie， że realizowanie funkcji kosztem struktury to postępowanie głupca。 To właśnie struktura kodu pozwala mu zachować Świetna książka， zawarte treści są b pomocne i aktualne， parę cytatów:Znacznie łatwiej jest nie być profesjonalistą。 Nie trzeba wtedy brać odpowiedzialności za swoją pracę — tę można pozostawić pracodawcom。 Jeżeli nieprofesjonalista popełnia błąd， to pracodawca musi po nim posprzątać。 Jeżeli jednak błąd popełnia profesjonalista， to sam stara się go skorygować。Prawdziwy zawodowiec wie， że realizowanie funkcji kosztem struktury to postępowanie głupca。 To właśnie struktura kodu pozwala mu zachować elastyczność。 Jeżeli naruszysz tę strukturę， zaszkodzisz przyszłości projektu。Ta filozofia czasami nazywana jest bezlitosną refaktoryzacją。 Ja nazywam ją „regułą skauta”: dany moduł zawsze pozostaw czystszy， niż go zastałeś。 Przeglądając kod， zawsze wyświadcz mu jakąś przysługę。Profesjonalni programiści są tak pewni swojego kodu i testów， że bez żadnych oporów prowadzają do kodu różne oportunistyczne zmiany。 Ot tak zmieniają nazwę klasy。 Jeżeli podczas czytania kodu modułu zauważą przydługą metodę， to przy okazji podzielą ją na mniejsze kawałki。 Zamienią instrukcję wyboru w rozwiązanie polimorficzne albo zwiną hierarchię dziedziczenia w strukturę typu łańcuch dowodzenia。 W skrócie: traktują oprogramowanie tak jak rzeźbiarz traktuje glinę — cały czas je przekształcają i formują。Być może nie chcesz takiego poświęcenia。 Nie ma sprawy， ale wtedy nie myśl o sobie jako o profesjonaliście。 Zawodowcy poświęcają czas， żeby zadbać o swoją profesję。To niezwykłe tempo zmian w naszej gałęzi przemysłu sprawia， że twórcy oprogramowania muszą ciągle przyswajać ogromne ilości wiedzy， tylko po to， żeby nadążyć za tym rozwojem。 Biada architektowi， który zaprzestanie tworzenia kodu。 Bardzo szybko okaże się， że nie przystaje do rzeczywistości。Chcesz korzystać z usług doktora， który przestał czytać o najnowszych postępach w medycynie？ Zatrudnisz doradcę podatkowego， który nie śledzi najnowszych zmian w prawie？ Dlaczego zatem mielibyśmy zatrudniać programistów， którzy nie śledzą nowości？Jest niewiele osób， które mówiąc o czymś， zamierzają to zrobić， a potem rzeczywiście zabierają się do roboty。 Są też tacy ludzie， którzy mówiąc o czymś， rzeczywiście zamierzają się tym zająć， ale w końcu i tak nic nie robią。 Ale najwięcej jest osób obiecujących różne rzeczy， które tak naprawdę nawet nie zamierzają się nimi zająć。To też się zdarza。 Czasami dzieją się rzeczy nieoczekiwane; takie jest życie。 Ale mimo to chcemy sprostać oczekiwaniom。 W takim wypadku należy zmieniać te oczekiwania tak wcześnie， jak tylko jest to możliwe。 Jeżeli nie jesteś w stanie dotrzymać zobowiązania， to najważniejsze jest jak najwcześniejsze podniesienie czerwonej flagi。Tworzenie kodu jest bardzo wyczerpującą czynnością i ogromnym wyzwaniem intelektualnym。 Wymaga ono osiągnięcia pewnego poziomu koncentracji i skupienia， niezbędnego tylko w kilku innych dziedzinach。Jeżeli jesteś zmęczony lub brakuje Ci skupienia， to nie twórz kodu。 Ostatecznie staniesz przed koniecznością ponownego wykonania tej samej pracy。 Lepiej będzie od razu wyeliminować elementy rozpraszające i uspokoić swój umysł。Nie opieraj się na nadziei， że zdołasz zrobić wszystko w 10 dni！ Nadzieja jest zabójcą projektów。 Nadzieja niszczy plany i rujnuje reputację。 Nadzieja wpędzi Cię w poważne tarapaty。 Jeżeli targi zaczynają się za 10 dni， a Twoja szacunkowa， normalna data ukończenia to 12 dni， to znaczy， że nie zdążysz na czas。 Upewnij się， że cały zespół i udziałowcy znają szczegóły sytuacji， i nie odpuszczaj， dopóki nie powstanie plan awaryjny。 Nie dawaj innym fałszywej nadziei。Co zrobić， jeżeli przełożony usadza Cię i prosi o próbę dotrzymania terminu？ Co zrobić， jeżeli kierownik nastaje， żeby „zrobić， co trzeba”？ Nie koryguj swoich szacunków！ Twoje pierwotne szacunki będą o wiele dokładniejsze niż wszelkie zmiany， jakie wprowadzisz do nich podczas takiej konfrontacji z szefem。 Powiedz szefowi， że wszelkie możliwości zostały już wzięte pod uwagę （bo tak się stało） i jedyną metodą poprawienia planu jest redukcja zakresu projektu。 Nie ulegaj pokusom przyspieszenia prac。Oznacza to， że nie należy zgadzać się na nadgodziny， chyba że （1） możesz sobie na to pozwolić， （2） jest to rozwiązanie krótkoterminowe， maksymalnie na dwa tygodnie i （3） Twój szef ma już plan awaryjny na wypadek， gdyby praca w nadgodzinach nie wystarczyła。 Ten ostatni warunek jest tutaj najważniejszy。 Jeżeli Twój szef nie jest w stanie stwierdzić， co zrobi， jeżeli nadgodziny nie przyniosą oczekiwanych efektów， to nie zgadzaj się na dodatkowe godziny pracy。Jeżeli ktoś proponuje Ci swoją pomoc， okaż mu wdzięczność。 Przyjmij ją i staraj się ją jak najlepiej wykorzystać。 Nie chroń swojego terytorium。 Nie rezygnuj z oferowanej pomocy， nawet jeżeli masz nóż na gardle。 Poświęć na ten cel jakieś pół godziny。 Jeżeli przez ten czas okaże się， że kolega nie jest w stanie Ci pomóc， to pięknie mu podziękuj i zakończ sesję。 Pamiętaj， że tak jak honor zobowiązuje Cię do udzielania pomocy， tak i zobowiązuje Cię do jej przyjmowania。Naucz się też prosić o pomoc。 Jeżeli utkniesz， dopadnie Cię zamroczenie albo po prostu nie będziesz w stanie ogarnąć problemu， to poproś kogoś o pomoc。 Jeżeli siedzisz w pokoju z całym zespołem， możesz po prostu wstać i powiedzieć: „Potrzebuję pomocy”。 W innych okolicznościach wykorzystaj Tweetera， e-mail albo telefon stojący na biurku i poproś kogoś o pomoc。 Powtarzam raz jeszcze， że jest to kwestia etyki zawodowej。 Zdecydowanie nieprofesjonalne jest stanie w miejscu， podczas gdy pomoc jest tak łatwo dostępna。Trzy prawa TDD Nie wolno napisać Ci nawet wiersza produktywnego kodu， jeżeli wcześniej nie napiszesz pasującego testu jednostkowego， który nie zostanie zaliczony。 Nie wolno Ci napisać więcej testu jednostkowego， niż jest konieczne， żeby test nie został zaliczony。 Nieudana kompilacja też powoduje， że test nie jest zaliczany。 Nie wolno Ci napisać więcej produktywnego kodu， niż potrzeba， żeby aktualnie oblany test został zaliczony。Testy akceptacyjne nie są testami jednostkowymi。 Testy jednostkowe są pisane przez programistów dla programistów。 Są formalnymi dokumentami projektowymi opisującymi najniższą strukturę i zachowanie kodu。 Odbiorcami tych testów są inni programiści， nikt inny。Po pierwsze， mimo że testują te same rzeczy， to jednak robią to za pomocą innych mechanizmów i ścieżek。 Testy jednostkowe dobierają się do wnętrzności systemu i wywołują poszczególne metody w wybranych klasach。 Testy akceptacyjne korzystają z systemu na znacznie wyższym poziomie: na poziomie API， a nawet interfejsu użytkownika。 Oznacza to， że ścieżka wykonania w tych testach jest odmienna。Jednym z najważniejszych zadań Twojego kierownika jest ograniczanie liczby Twoich spotkań。 Dobry menedżer będzie bardzo chętnie bronił Twojej decyzji o odmowie udziału w spotkaniu， ponieważ powinien on na równi z Tobą przejmować się wykorzystaniem Twojego czasu。Oczywiście nie należy wybiegać z pokoju konferencyjnego， krzycząc: „Ale nudy！”。 To byłoby niegrzeczne。 Możesz jednak we właściwym momencie zapytać， czy Twoja obecność jest konieczna。 Należy wtedy wyjaśnić， że nie masz aż tyle czasu do dyspozycji， i poprosić o przyspieszenie dyskusji albo zmianę planu spotkania。Kent Beck powiedział mi kiedyś coś bardzo ważnego: „Każda kłótnia， której nie da się załagodzić w 5 minut， nie zostanie załagodzona w ramach dalszej kłótni”。 Powodem takiego przeciągania sprawy jest to， że żadna ze stron nie może znaleźć konkretnego dowodu potwierdzającego jej tezy。 Takie kłótnie są najzwyczajniej religijne， w przeciwieństwie do kłótni bazujących na faktach。Każda ze stron ma pewne umocowania swoich poglądów， ale rzadko dysponuje jakimikolwiek danymi。 Bez danych w każdej kłótni， w której nie uda się zawrzeć porozumienia w ciągu kilku minut （pomiędzy 5 a 30）， nie ma najmniejszych szans na porozumienie。 Jedynym rozwiązaniem jest dostarczenie niezbędnych danych。Niektórzy mogą zachowywać się pasywno-agresywnie。 Zgadzają się na zakończenie sporu， a potem sabotują wyniki， odmawiając swojego zaangażowania w rozwiązanie。 Tacy ludzie mówią sobie: „Przecież tego chcieli， a zatem dostaną dokładnie to， o co prosili”。 To chyba najgorszy z możliwych przykład nieprofesjonalnego zachowania。 Nigdy nie należy tak postępować。 Jeżeli się na coś zgadzasz， to musisz się w to zaangażować。Programowanie jest ćwiczeniem intelektualnym， które wymaga długich okresów koncentracji i skupienia。 Skupienie jest niestety bardzo rzadkim dobrem， podobnie jak manna[1]。 Po wyczerpaniu swojej manny skupienia musisz ją uzupełnić， wykonując przez przynajmniej godzinę czynności niewymagające koncentracji。Sposobem na szybki rozwój projektu i dotrzymywanie wszystkich terminów jest odpowiednie utrzymanie czystości。 Profesjonaliści nie poddają się pokusie tworzenia bałaganiarskiego kodu tylko po to， żeby robić to szybciej。 Profesjonaliści wiedzą doskonale， że wyrażenie „szybko i paskudnie” to oksymoron。 Paskudny kod zawsze oznacza spowolnienie！Poinformuj swój zespół i przełożonego o kłopotach。 Przedstaw im swój plan wybrnięcia z nich i poproś o uwagi i wskazówki。 Unikaj niespodzianek。 Poza niespodziankami chyba nic nie wprawia ludzi w większy gniew i nie prowokuje do mniej racjonalnych zachowań。 Niespodzianki dziesięciokrotnie zwiększają presję。Większość oprogramowania jest tworzona przez zespoły。 Zespoły działają najskuteczniej， gdy ich członkowie profesjonalnie ze sobą współpracują。 Nieprofesjonalne jest bycie w zespole odludkiem i samotnikiem。Jednym z najgorszych symptomów dysfunkcyjnego zespołu jest sytuacja， w której każdy programista tworzy mur otaczający jego kod i odmawia pozostałym prawa do zmian。 Bywałem w miejscach， w których programiści nie pozwalali innym nawet zobaczyć swojego kodu。 To prosta recepta na katastrofę。Profesjonalni programiści nie zabraniają innym pracy nad swoim kodem。 Nie budują na około niego murów。 Starają się raczej współpracować ze sobą nad wspólnym rozwijaniem systemu。 Uczą się nawzajem， pracując wspólnie nad różnymi częściami systemu。Banki i firmy ubezpieczeniowe próbowały tworzyć zespoły na potrzeby projektów。 To jednak jest nierozsądne podejście。 Zespołu nie da się szybko zintegrować。 Poszczególne osoby uczestniczą w projekcie przez krótki czas， poświęcając mu tylko część swojej uwagi， i dlatego nigdy nie uczą się， jak ze sobą współpracować。 Profesjonalne organizacje rozwojowe przypisują projekty istniejącym już zintegrowanym zespołom， ale nie formują zespołów na potrzeby projektów。 Zespolony zespół może przyjąć jednocześnie kilka różnych projektów i podzielić prace zgodnie z własnym uznaniem i umiejętnościami。 Zespolony zespół na pewno sobie z takimi projektami poradzi。Zespoły tworzy się trudniej niż projekty。 Z tego powodu lepiej jest tworzyć trwałe zespoły， które razem pracują nad kolejnymi projektami i mogą obsługiwać w danym czasie kilka projektów。 Celem formowania zespołu jest przekazanie mu wystarczającej ilości czasu na zintegrowanie się。 Później taki zespół nie powinien być rozbijany， ponieważ jest on gotowy na realizację wielu projektów。 。。。more

SaratCR ，

Hands down one of my best reads。 Loved every minute of the read。 A must read for every software developer。

Yure Kesley ，

Incredible book。 This is a guide for all that want to become a great programmer。 If you follow all tips contained in this book， I'm sure， you will reap all the benefits。 Incredible book。 This is a guide for all that want to become a great programmer。 If you follow all tips contained in this book， I'm sure， you will reap all the benefits。 。。。more

Mantas Serapinas ，

Some parts are really outdated but overall a very informative and motivating book。 Definitely， worth rereading once in a while to remind oneself of what it takes to be a professional in software engineering。

Domas Dz。 ，

A very nice overview of good practices， disciplines and almost everything in between。 A must pick for a software engineer in beginning years。 However， while reading I sometimes felt it's a bit moldy， especially examples A very nice overview of good practices， disciplines and almost everything in between。 A must pick for a software engineer in beginning years。 However， while reading I sometimes felt it's a bit moldy， especially examples 。。。more

Amir Tesla ，

A book of work ethics for professional developers。

Max Huynh ，

This book is definitely super useful and should be a must-read for graduate and junior software developer。 It helps you prepare your mindset for your first professional role after graduation （still helpful if you just got a formal notice or booted from your previous job :P ， it's time to fix up everything right？ ）。I've read several technical books and none of them give you this level of experience on how to work and communicate like a professional。 This book is definitely super useful and should be a must-read for graduate and junior software developer。 It helps you prepare your mindset for your first professional role after graduation （still helpful if you just got a formal notice or booted from your previous job :P ， it's time to fix up everything right？ ）。I've read several technical books and none of them give you this level of experience on how to work and communicate like a professional。 。。。more

Amila Fonseka ，

Helped me immensely to learn how to be a true 'Professional' in the programming field。 Highly recommend it。 Helped me immensely to learn how to be a true 'Professional' in the programming field。 Highly recommend it。 。。。more

David Cozens ，

Very clear and thought provoking。 Not quite the same league as Clean Code。 Great tips on being a professional software engineer。 So many of Bob's anecdotes remind me of experiences over the years。 Very clear and thought provoking。 Not quite the same league as Clean Code。 Great tips on being a professional software engineer。 So many of Bob's anecdotes remind me of experiences over the years。 。。。more

Thomas Neil ，

I would， in hindsight， consider this to be the introduction to the practice of programming professionally I wish I had after coding bootcamp and the book to read sequentially before Clean Code。 Anecdotes provided are not always understandable to me as someone who will not learn Assembly， but the principles around professionalism are universally true and applicable。 I have found estimation， planning， self management， teamwork and communication all are unique skill sets to cultivate as a coder， an I would， in hindsight， consider this to be the introduction to the practice of programming professionally I wish I had after coding bootcamp and the book to read sequentially before Clean Code。 Anecdotes provided are not always understandable to me as someone who will not learn Assembly， but the principles around professionalism are universally true and applicable。 I have found estimation， planning， self management， teamwork and communication all are unique skill sets to cultivate as a coder， and I don’t sense that I have reached any level of particular competence in those domains。 This book provided me with a useful framework for considering all of them。Lastly， as a huge fan of the concept of Flow， I would add that the 4th chapter provides a useful counterweight to this much obsessed over concept。 Is flow — aka putting your head down and just doing something without interaction or testing your assumptions with teammates — really the correct way to think about the ideals of work for someone still needing to grow and have one’s assumptions challenged ？ I’d suggest， as Martin does， no。 。。。more

Giri ，

When Uncle Bob with his 50+ years of software engineering experience talk， you listen！This book talks about being a "professional" in software engineering field。 Uncle Bob talks about how best to set timelines for ourselves， collaborate with others， give estimates for the project， Time management， mentoring， and much， much more！There are also many "back in the day。。。" moments where Uncle Bob explains about how he worked with nothing but buttons and bulbs to code his own operating system。 Makes y When Uncle Bob with his 50+ years of software engineering experience talk， you listen！This book talks about being a "professional" in software engineering field。 Uncle Bob talks about how best to set timelines for ourselves， collaborate with others， give estimates for the project， Time management， mentoring， and much， much more！There are also many "back in the day。。。" moments where Uncle Bob explains about how he worked with nothing but buttons and bulbs to code his own operating system。 Makes you give perspective， and appreciate the fancy IDEs that we know take for granted。 If you're a software developer， you'll find this book invaluable。 。。。more

Snowfox ，

a must read for every software engineer

Reference

google book https://www.google.com/search?tbm=bks&q=The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

hathitrust digital library https://babel.hathitrust.org/cgi/ls?q1=The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)&field1=ocr&a=srchls&ft=ft&lmt=ft

The British Library https://bll01.primo.exlibrisgroup.com/discovery/search?query=any,contains,The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)&tab=LibraryCatalog&search_scope=Not_BL_Suppress&vid=44BL_INST:BLL01&lang=en&offset=0